InfoMagic Standards 1994 January/InfoMagic Standards - January 1994.iso/inet/ietf/smds/90jul.min

Text File | 1993-02-17 | 8KB | 220 lines

CURRENT_MEETING_REPORT_


Reported by George Clapp/Ameritech

SMDS Minutes

Review of Draft Document

The IP over Switched Multi-megabit Data Service (SMDS) Working Group met
for three half-day sessions.  The majority of the time was spent
reviewing the text of a draft document, A Proposed Standard for the
Transmission of IP Datagrams over SMDS, written by Dave Piscitello and
Joe Lawrence.  The configuration assumed in the document was that of a
Logical IP Subnet (dubbed an LIS), in which a virtual private network
supported by SMDS was treated as an IP network/subnet.  The following
are the requirements for an LIS configuration:


   o All members have the same IP network/subnetwork number.
   o All stations within an LIS are accessed directly over SMDS.
   o All stations outside of the LIS are accessed via a router.
   o For each LIS, a single SMDS group address (smds$ip_ga) has been
     configured that identifies all members of the LIS.


The protocol stack is assumed to be that depicted below in figure 1.


               ---------------------------------------------
               |                   IP/ARP                  |
               ---------------------------------------------
               |      Subnetwork Access Protocol (SNAP)    |
               ---------------------------------------------
               |             IEEE 802.2 LLC Type 1         |
               ---------------------------------------------
               |SMDS Interface Protocol (SIP) Level 3 (MAC)|
               ---------------------------------------------
               |                 SIP Level 2               |
               ---------------------------------------------
               |                 SIP Level 1               |
               ---------------------------------------------

                                  Figure 1



In addition to the SMDS individual address associated with the
Subscriber Network Interface (SNI), and to the SMDS group address
associated with the LIS, the document referred to a third SMDS group
address, the SMDS ARP Request Address (smds$arp_req).  This group
address is set to smds $ip_ga, but latter implementations may set the

                                   1






address to a subset of the addresses in the LIS to deal with scaling
issues.

The dynamic mapping of 32 bit Internet addresses to 60 bit SMDS
addresses is done via Address Resolution Protocol (ARP). ARP requests
will be multicast to the smds$arp_req address.  The ARP parameters which
require specification are the following:


ar$hrd  16 bits hardware type code           <to be determined>
ar$pro  16 bits protocol type code           decimal 2048 for IP
ar$hln  8 bits octets in hardware address    decimal 8 for 64 bits
ar$pln  8 bits octets in protocol address    decimal 4 for 32 bits
ar$op   16 bits operation code               1:  request
                                            2:  reply



Dave Piscitello volunteered to contact Joyce Reynolds to obtain a value
for the hardware type code.

An issue arose during the discussion of ARP over SMDS concerning the
encoding of the SMDS address in the ARP reply message.  Following the
precedence of the IP over FDDI Working Group, the document specified
that the SMDS address will be carried in ``canonical'' format, which is
the format specified in the IEEE P802.1A/D10 draft standard, in which
the least significant bit of the most significant octet is transmitted
first.  The encoding of the 60 bit address within the SIP L_3 PDU does
not conform to the canonical format, and the bits of each octet would
have to be reversed.  The use of the canonical format is important in
transparent bridging, when LANs of a similar address space but of
dissimilar address encoding schemes may be bridged.  However, the group
questioned the utility of transparent bridging between 802 LANs with a
48 bit address space and SMDS with a 60 bit address space.  This
questionable utility was compared with the potential for confusion
caused by the reversal of bits in the SMDS address.  In the end, the
group decided not to use the canonical format, but instead to use the
format specified for the SMDS ``MAC'' header.

No unresolved issues remained with the document and the group asked Joe
Lawrence to incorporate the suggested modifications and to release the
document to the email group for confirmation.  Joe indicated that he
might be able to release the document by mid-August.

Public Connectivity

It was felt that the draft document was adequate to define the operation
of IP over small virtual private networks supported by SMDS. Discussion
then turned to the issue of ``public connectivity,'' in which an SMDS
device may communicate directly with any other SMDS device.  The
question was asked of this model ``What breaks?'', and the following
items were listed:

                                   2






   o ARP
   o Routing:  cost, traffic volume, table sizes
   o Address management


The group was then asked whether there was any interest in pursuing this
problem, and discussion led to an offer by Manoel Rodrigues and George
Clapp to draft an ``issues'' document to attempt to clarify the issues
left unresolved by the draft document.

Support of Other Protocols

Vicki Ralls pointed out that other protocols such as DECNET and XNS also
need a specification to operate over SMDS, and asked whether this was of
interest to the group.  The group felt that IP was the appropriate topic
for their work and suggested that Bellcore might be approached
concerning these other protocols.

Network Management

Dave Piscitello distributed copies of three papers on network management
relevant to SMDS.


   o Experimental Definitions of Managed Objects for the SMDS Interface
     Protocol (sip) Interface Type, Kaj Tesink
   o Experimental Definitions of Managed Objects for the t3-carrier
     Interface Type, Tracy Cox, Kaj Tesink
   o Internet Draft of T1-Carrier objects, Kaj Tesink, Tracy Cox


These documents were distributed to the Working Group on an
informational basis to the.  The first two documents had been submitted
for consideration by the TransMIB Working Group; the third had not been
submitted since the points raised in the document had already been
addressed by the TransMIB group.

Future Work

The work remaining for the group will be to review and possibly approve
the draft document.  The group may be able to approve the document at
the upcoming meeting in December and, if possible, begin the process of
submitting the document to become an RFC. At the same meeting, the group
may review the document to be written by Manoel Rodrigues and George
Clapp.

During the IETF Plenary of Friday morning, August 3rd, Bob Hinden
announced the formation of a new Working Group within the routing area,
Address Resolution and Routing over SMDS and X.25 Public Data Networks.
This group will be chaired by George Clapp and may investigate some of
the issues left unresolved by the IP over SMDS Working Group.


                                   3






Attendees


Douglas Bagnall          [e-mail]
Chet Birger              [e-mail]
Roger Boehner            [e-mail]
Caralyn Brown            [e-mail]
Asheem Chandna           [e-mail]
George Clapp             meritec![e-mail]
Tracy Cox                [e-mail]
Caroline Cranfill        [e-mail]
Kevin Fall               [e-mail]
Michael Fidler           [e-mail]
James Forster            [e-mail]
Craig Fox                [e-mail]
Eugene Geer              bcr!nvmxr!ewg
Neil Haller              [e-mail]
Dave Kaufman             [e-mail]
Alex Koifman             [e-mail]
Joseph Lawrence          [e-mail]
Walter Lazear            [e-mail]
Alan Menezes             [e-mail]
David Piscitello         [e-mail]
Vicki Ralls              [e-mail]
Michael Reilly           [e-mail]
Ron Roberts              [e-mail]
Manuel Rodrigues
Jim Showalter            [e-mail]
Frank Slaughter          [e-mail]
Zaw-Sing Su              [e-mail]
Gregory Vaudreuil        [e-mail]
Chris Weider             [e-mail]
Steve Willis             [e-mail]



                                   4